Internet Engineering Task Force (IETF) T. Kause 


Request for Comments: 6712 SSH 
Updates: 4210 M. Peylo 
Category: Standards Track NSN 
ISSN: 2070-1721 September 2012 
Internet X.509 Public Key Infrastructure -- HTTP Transfer 


for the Certificate Management Protocol (CMP) 
Abstract 
This document describes how to layer the Certificate Management 
Protocol (CMP) over HTTP. It is the "CMPtrans" document referenced 
in RFC 4210; therefore, this document updates the reference given 
therein. 
Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6712. 
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This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
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1. Introduction 


The Certificate Management Protocol (CMP) [RFC4210] requires a well- 
defined transfer mechanism to enable End Entities (EEs), Registration 
Authorities (RAs), and Certification Authorities (CAs) to pass 
PKIMessage sequences between them. 


The first version of the CMP specification [RFC2510] included a brief 
description of a simple transfer protocol layer on top of TCP. Its 
features were simple transfer-level error handling and a mechanism to 
poll for outstanding PKI messages. Additionally, it was mentioned 
that PKI messages could also be conveyed using file-, E-mail-, and 
HTTP-based transfer, but those were not specified in detail. 
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The current version of the CMP specification [RFC4210] incorporated 
its own polling mechanism, and thus the need for a transfer protocol 
providing this functionality vanished. The remaining features CMP 
requires from its transfer protocols are connection and error 
handling. 


Before this document was published as an RFC, the draft version 
underwent drastic changes during the long-lasting work process. The 
so-called "Direct TCP-Based Management Protocol" specified in 
[RFC2510] was enhanced, and at some point a version existed where 
this protocol was again transferred over HTTP. As both approaches 
proved to be needless and cumbersome, implementers preferred to use 
plain HTTP transfer following [RFC1945] or [RFC2616]. This document 
now reflects that by exclusively describing HTTP as the transfer 
protocol for CMP. 


The usage of HTTP for transferring CMP messages exclusively uses the 
POST method for requests, effectively tunneling CMP over HTTP. While 
this is generally considered bad practice and should not be emulated, 
there are good reasons to do so for transferring CMP. HTTP is used 
as it is generally easy to implement and it is able to traverse 
network borders utilizing ubiquitous proxies. Most importantly, HTTP 
is already commonly used in existing CMP implementations. Other HTTP 
request methods, such as GET, are not used because PKI management 
operations can only be triggered using CMP’s PKI messages, which need 
to be transferred using a POST request. 


With its status codes, HTTP provides needed error reporting 


capabilities. General problems on the server side, as well as those 
directly caused by the respective request, can be reported to the 
client. 


As CMP implements a transaction ID, identifying transactions spanning 
over more than just a single request/response pair, the statelessness 
of HTTP is not blocking its usage as the transfer protocol for CMP 
messages. 


2. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 

3. HTTP-Based Protocol 
For direct interaction between two entities, where a reliable 


transport protocol like TCP is available, HTTP SHOULD be utilized for 
conveying CMP messages. 
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3.1. HTTP Versions 


Implementations MUST support HTTP/1.0 [RFC1945] and SHOULD support 
HTTP/1.1 [RFC2616]. 


3.2. Persistent Connections 


HTTP persistent connections [RFC2616] allow multiple interactions to 
take place on the same HTTP connection. However, neither HTTP nor 
the protocol specified in this document are designed to correlate 
messages on the same connection in any meaningful way; persistent 
connections are only a performance optimization. In particular, 
intermediaries can do things like mix connections from different 
clients into one "upstream" connection, terminate persistent 
connections, and forward requests as non-persistent requests, etc. 
As such, implementations MUST NOT infer that requests on the same 
connection come from the same client (e.g., for correlating PKI 
messages with ongoing transactions); every message is to be evaluated 
in isolation. 


3.3. General Form 


A DER-encoded [ITU.X690.1994] PKIMessage [RFC4210] is sent as the 
entity-body of an HTTP POST request. If this HTTP request is 
successful, the server returns the CMP response in the body of the 
HTTP response. The HTTP response status code in this case MUST be 
200; other "Successful 2xx" codes MUST NOT be used for this purpose. 
HTTP responses to pushed CMP Announcement messages (i.e., CA 
Certificate Announcement, Certificate Announcement, Revocation 
Announcement, and Certificate Revocation List (CRL) Announcement) 
utilize the status codes 201 and 202 to identify whether the received 
information was processed. 


While "Redirection 3xx" status codes MAY be supported by 
implementations, clients should only be enabled to automatically 
follow them after careful consideration of possible security 
implications. As described in Section 5, "301 Moved Permanently" 
could be misused for permanent denial of service. 


All applicable "Client Error 4xx" or "Server Error 5xx" status codes 
MAY be used to inform the client about errors. 


3.4. Media Type 


The Internet Media Type "application/pkixcmp" MUST be set in the HTTP 
Content-Type header field when conveying a PKIMessage. 
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3.5. Communication Workflow 


In CMP, most communication is initiated by the EEs where every CMP 
request triggers a CMP response message from the CA or RA. 


The CMP Announcement messages described in Section 3.7 are an 
exception. Their creation may be triggered by certain events or done 
on a regular basis by a CA. The recipient of the Announcement only 
replies with an HTTP status code acknowledging the receipt or 
indicating an error, but not with a CMP response. 


If the receipt of an HTTP request is not confirmed by receiving an 
HTTP response, it MUST be assumed that the transferred CMP message 
was not successfully delivered to its destination. 


3.6. HTTP Request-URI 
The Request-URI is formed as specified in [RFC3986]. 


A server implementation MUST handle Request-URI paths, with or 
without a trailing slash, as identical. 


An example of a Request-Line and a Host header field in an HTTP/1.1 
header, sending a CMP request to a server, located in the "/cmp" path 
of the host "example.com", would be 


POST /cmp HTTP/1.1 
Host: example.com 


or in the absoluteURI form 


POST http://example.com/cmp/ HTTP/1.1 
Host: example.com 


3.7. Pushing of Announcements 


A CMP server may create event-triggered announcements or generate 
them on a regular basis. It MAY utilize HTTP transfer to convey them 
to a suitable recipient. In this use case, the CMP server acts as an 
HTTP client, and the recipient needs to utilize an HTTP server. As 
no request messages are specified for those announcements, they can 
only be pushed to the recipient. 


If an EE wants to poll for a potential CA Key Update Announcement or 


the current CRL, a PKI Information Request using a General Message as 
described in Appendix E.5 of [RFC4210] can be used. 


Kause & Peylo Standards Track [Page 5] 


RFC 6712 CMPtrans September 2012 


When pushing Announcement messages, PKIMessage structures are sent as 
the entity-body of an HTTP POST request. 


Suitable recipients for CMP announcements might, for example, be 
repositories storing the announced information, such as directory 
services. Those services listen for incoming messages, utilizing the 
same HTTP Request-URI scheme as defined in Section 3.6. 


The following PKIMessages are announcements that may be pushed by a 
CA. The prefixed numbers reflect ASN.1 numbering of the respective 
element. 


[15] CA Key Update Announcement 
[16] Certificate Announcement 
[17] Revocation Announcement 
[18] CRL Announcement 


CMP Announcement messages do not require any CMP response. However, 
the recipient MUST acknowledge receipt with an HTTP response having 
an appropriate status code and an empty body. When not receiving 
such a response, it MUST be assumed that the delivery was not 
successful. If applicable, the sending side MAY try sending the 
Announcement again after waiting for an appropriate time span. 


If the announced issue was successfully stored in a database or was 
already present, the answer MUST be an HTTP response with a "201 
Created" status code and an empty message body. 


In case the announced information was only accepted for further 
processing, the status code of the returned HTTP response MAY also be 
"202 Accepted". After an appropriate delay, the sender may then try 
to send the Announcement again and may repeat this until it receives 
a confirmation that it has been successfully processed. The 
appropriate duration of the delay and the option to increase it 
between consecutive attempts should be carefully considered. 


A receiver MUST answer with a suitable 4xx or 5xx HTTP error code 
when a problem occurs. 


3.8. HTTP Considerations 


While all defined features of the HTTP protocol are available to 
implementations, they SHOULD keep the protocol utilization as simple 
as possible. For example, there is no benefit in using chunked 
Transfer-Encoding, as the length of an ASN.1 sequence is known when 
starting to send it. 
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There is no need for the clients to send an "Expect" request—header 
field with the "100-continue" expectation and wait for a "100 
Continue" status as described in Section 8.2.3 of [RFC2616]. The CMP 
payload sent by a client is relatively small, so having extra 
messages exchanged is inefficient, as the server will only seldom 
reject a message without evaluating the body. 


4. Implementation Considerations 


Implementors should be aware that implementations might exist that 
use a different approach for transferring CMP over HTTP, because this 
document has been under development for more than a decade. Further, 
implementations based on earlier drafts of this document might use an 
unregistered "application/pkixcmp-—poll" MIME type. 


5. Security Considerations 


The following aspects need to be considered by implementers and 
users: 


1. There is the risk for denial-of-service attacks through resource 
consumption by opening many connections to an HTTP server. 
Therefore, idle connections should be terminated after an 
appropriate timeout; this may also depend on the available free 
resources. After sending a CMP Error Message, the server should 
close the connection, even if the CMP transaction is not yet 
fully completed. 


2. Without being encapsulated in effective security protocols, such 
as Transport Layer Security (TLS) [RFC5246], there is no 
integrity protection at the HTTP protocol level. Therefore, 
information from the HTTP protocol should not be used to change 
state of the transaction. 


3. Client users should be aware that storing the target location of 
an HTTP response with the "301 Moved Permanently" status code 
could be exploited by a man-in-the-middle attacker trying to 
block them permanently from contacting the correct server. 


4. If no measures to authenticate and protect the HTTP responses to 
pushed Announcement messages are in place, their information 
regarding the Announcement’s processing state may not be trusted. 
In that case, the overall design of the PKI system must not 
depend on the Announcements being reliably received and processed 
by their destination. 
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6. 


5. CMP provides inbuilt integrity protection and authentication. 
The information communicated unencrypted in CMP messages does not 
contain sensitive information endangering the security of the PKI 
when intercepted. However, it might be possible for an 
eavesdropper to utilize the available information to gather 
confidential technical or business critical information. 
Therefore, users of the HTTP transfer for CMP might want to 
consider using HTTP over TLS according to [RFC2818] or virtual 
private networks created, for example, by utilizing Internet 
Protocol Security according to [RFC4301]. Compliant 
implementations MUST support TLS with the option to authenticate 
both server and client. 


IANA Considerations 


The IANA has already registered the MIME media type "application/ 
pkixcmp" for identifying CMP sequences due to an request made in 
connection with [RFC2510]. 


No further action by the IANA is necessary for this document or any 
anticipated updates. 
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